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A Direction for IPng 
Status of this Memo 


This memo provides information for the Internet community. This memo 
does not specify an Internet standard of any kind. Distribution of 
this memo is unlimited. 


Abstract 


This document was submitted to the IPng Area in response to RFC 1550. 
Publication of this document does not imply acceptance by the IPng 
Area of any ideas expressed within. Comments should be submitted to 
the big-internet@munnari.oz.au mailing list. This RFC specifies 
criteria related to mobility for consideration in design and 
selection of the Next Generation of IP. 
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1. Introduction 


At the Amsterdam IETF meeting, we held a BOF, entitled the "IPDecide 
BOF", on the process and progress of the IPng activities. 


("IPng" stands for "IP, the next generation". The IPDecide BOF was 
chaired by Brian Carpenter. Minutes are available in the IETF 
directories, with the file name </ietf/93 jul/ipdecide-minutes- 
93jul.txt>.) 


The IPDecide BOF explored several facets of the IPng process, such 
as: 


"What is the basis for choosing the next generation IP (i.e., what 
are the technical requirements and decision criteria) ." 
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"With the advent of CIDR and new, more stringent address 
assignment policies, are we comfortable that we truly understand 
the level of urgency?" 


"Should the IETF or the marketplace make the final IPng decision". 


The BOF was held in a productive atmosphere, but did not achieve what 
could be called a clear consensus among the assembled attendees. In 
fact, despite its generally productive spirit, it did more to 
highlight the lack of a firm direction than to create it. 


The IPDecide BOF was followed the next evening by the open IESG 
plenary. During this session, the IESG and the assembled attendees 
discussed the IPng issues and seemed to arrive at a consensus based 
on the following set of bullets presented by the IETF chair: 


"The IETF needs to move toward closure on IPng." That is, the 
IETF should take active steps toward a technical decision, rather 
than waiting for the "marketplace" to decide. 


"The IESG has the responsibility for developing an IPng 
recommendation for the Internet community." That is, the IESG 
should provide leadership and take specific actions to help move 
the IETF toward a technical decision. 


"The procedures of the recommendation-making process should be 
open and published well in advance by the IESG." 


"As a part of the process, the IPng WGs may be given new 
milestones and other guidance to aid the IESG." 


"There should be ample opportunity for community comment prior to 
final IESG recommendation (e.g., there will be an extended Last 
Call) ." 


2. A Direction For IPng 
Building on this consensus, I’d like to announce a set of specific 


directions in the IESG that I hope will move us toward timely 
resolution of many of the key IPng issues. 


The IESG will establish a temporary, ad hoc, "area" to deal 


specifically with IPng issues. The charter for this new IESG area 
is to develop a recommendation on which, if any, of the current 
proposals should be adopted as the "next IP". This recommendation 


will be submitted to the IESG and to the Internet community for 
review. Following an adequate period of review to surface any 
community concerns, the IESG will issue a final IPng recommendation. 
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All of the current IPng-related working groups will be moved 
immediately into this new area. 


This new area will be headed by two co-Area Directors from within the 
IESG. I have asked Allison Mankin (NRL), current Transport Services 
AD, and Scott Bradner (Harvard), current Operational Requirements AD, 
to serve as co-AD’s for this temporary area. I am very pleased to 
report that they have agreed to take this important assignment. 
(Because this is expected to be a temporary assignment, Scott and 
Allison will also continue to serve in their current IESG positions 
during this period.) 


All IETF Areas are now expected to have Area Directorates. For the 
IPng Area, a Directorate will be especially important to bring 
additional viewpoints into the process. Therefore, I am asking that, 
as their first action, Scott and Allison form a specific IPng 
Directorate to act as a direction-setting and preliminary review 
body. The IPng process will continue to be completely open, and 
therefore reports and meeting notes from any IPng Directorate 
meetings will be published in timely fashion. 


3. Issues Toward IPng Resolution 


Two important issues need resolution immediately before we can expect 
progress toward an IPng recommendation: 


- What is the scope of the effort? 


That is, should IPng be limited to solving the well known scaling 
and address exhaustion issues; or should IPng also include 
advanced features such as resource reservation for real-time 
traffic? 


The argument in favor of considering advanced features is that 
migration to a new IP is (hopefully, only!) a once-in-a-generation 
occurrence, and therefore all advanced features should at least be 
considered. 


Arguments opposed to considering advanced features include the 
fact that we may not have time for this level of effort before the 
scaling and address exhaustion problems confront us, and that we 
may not have the necessary understanding and experience to make 
all the correct choices at this time. 
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- What is the available timeframe? 


That is, before we can even begin to make an informed decision 
about the scope, we need a better understanding of the urgency and 
time constraints facing us. 


Factors that affect the available time include the current rate of 
address assignments (which can give us an estimate of when we are 
currently projected to run out of addresses), the current policies 
governing address assignment (which can give us an understanding 
of how policies affect the assignment and utilization rates), the 
impact of CIDR aggregation, the development time for IPng, and the 
time needed to field and migrate to the new IPng. 


Therefore, I am asking the new AD’s and the Directorate to start 
immediately the following specific activities to help guide their 
ultimate IPng recommendation: 
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1. Develop an understanding of the available timeframe, covering 
at least the following issues: 


- Review Internet growth metrics, such as the current address 
assignment and utilization rates. Develop an understanding of 
how the new address assignment policies impact the assignment 
and utilization rates. 


- Review the expected impact of CIDR address aggregation. 
Develop an understanding of the expected savings due to CIDR 
aggregation. 


- Develop new technical guidelines for classless Internet 
addressing. Specific examples include guidelines for how to 
utilize variable length subnet masks, and how to utilize 
currently unused Class A and B addresses in a classless fashion 
in hosts and routers. 


- Develop a strong understanding of the time required for the 
development, fielding, and migration for a new IP. 


- Based on all the above issues, 
(a) develop an estimate for how long we have to develop 
and deploy an IPng. This could be a set of estimates 


based on best/worst case estimates for how each of the 
above factors will affect the available timeframe. 
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(b) Consider whether more stringent assignment policies 
might provide additional time. If so, recommend such 
policies. 


(c) make a recommendation on whether it is worthwhile to 
mount a serious effort to reclaim addresses and/or to 
renumber significant portions of the Internet. 


2. Based on an informed judgment of the time constraints above, 
make a recommendation regarding the scope for IPng, i.e., should 
IPng consider scaling issues only or advanced topics also. 


3. Based on the scope and time constraints, develop a clear and 
concise set of technical requirements and decision criteria for 
IPng. These should include, but not be limited to, the criteria 
outlined in the IESG statement (RFC1380). 


4. Based on the decision criteria, scope, and time constraints, 
make a recommendation on which of the current IPng candidates to 
accept, if any. 


Finally, I am asking Scott and Allison to make a detailed report 
at the opening plenary of the next IETF meeting in November on the 
status of setting up their new area, and on their progress toward 
organizing the above work items. In particular, the status of the 
work items on timeframe should be fully reported. This will be 
followed by regular progress reports to the Internet community, at 
IETF meetings and in other appropriate forums. 


Please join me in giving Scott and Allison our full cooperation, and 
in thanking them for accepting this daunting assignment. I feel 
confident that we will now make significant progress on the important 
IPng issues facing the Internet community. 


4. Security Considerations 

Security issues are not discussed in this memo. 
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